Git for Windows is the Windows port of Git. From 2.43.0.windows.1 until 2.55.0.windows.3, when a matching git: credential exists in Windows Credential Manager and a git-credential-wincred erase input includes a password field, the operation in contrib/credential/wincred/git-credential-wincred.c allocates a buffer of exactly CredentialBlobSize bytes in matchcredpassword() and then uses wcsncpys() to copy the corresponding number of wide characters plus a terminating NUL. The destination capacity is also supplied in bytes instead of WCHAR elements, allowing a fixed two-byte NUL write past the allocation before the password comparison determines whether CredDeleteW() should remove the credential; erase without a password field does not enter this comparison path. The helper can terminate with Windows heap-corruption status, and git credential reject can appear successful while the rejected credential remains stored. This issue is fixed in version 2.55.0.windows.3.

Git for Windows is the Windows port of Git. From 2.44.0.windows.1 until 2.55.0.windows.3, the git-credential-wincred store operation in contrib/credential/wincred/git-credential-wincred.c uses scwprintf() to size a formatted wide-character credential buffer without space for the terminating NUL when both password and oauthrefreshtoken are present. The operation also passes a byte count to snwprintfs() where a wide-character count is required, allowing the terminator to be written one WCHAR past the heap allocation before CredWriteW() persists the credential. The resulting fixed two-byte NUL overwrite can terminate the helper with Windows heap-corruption status and can cause git credential approve to report success even though the OAuth credential was not stored. This issue is fixed in version 2.55.0.windows.3.

Just wanted to flag one that might have slipped under yalls radar if you only focus on standard "Patch Tuesday". CVE-2025-66413 affects Git for Windows versions prior to 2.53.0(2). It allows an attacker to grab a user's NTLM hash just by tricking them into cloning a malicious repo. Since Git for Windows doesn't always auto-update through standard corporate channels I had to do some quick checking.

Management thinks we’re good but we're not. Found a bunch of devs running Git from their user profiles, so it never hits inventory. Spot-checked machines and versions all over the place, some pretty outdated. Security flagged the NTLM hash vuln, and everyone assumed Patch Tuesday covered it.

I put together a quick PowerShell script(read only) to help you find vulnerable versions of git.exe in your environment:

powershell $Target = "git.exe" $SearchPaths = @("$env:ProgramFiles", "${env:ProgramFiles(x86)}", "$env:LocalAppData\Programs") Get-ChildItem -Path $SearchPaths -Filter $Target -Recurse -ErrorAction SilentlyContinue | Select-Object FullName, @{Name="Version";Expression={$.VersionInfo.ProductVersion}} Threw the script up here in case it helps anyone else: https://www.cveintel.tech/cve/CVE-2025-66413/

Anyone else dealing with stuff like this?

> EDIT: Fixed the PowerShell formatting for easier copy-pasting.

Git for Windows is the Windows port of Git. Prior to 2.53.0(2), it is possible to obtain a user's NTLM hash by tricking them into cloning from a malicious server. Since NTLM hashing is weak, it is possible for the attacker to brute-force the user's account name and password. This vulnerability is fixed in 2.53.0(2).